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Foreword 



,rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document identifies the 3G system specifications for Release 5. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the CAMEL AppHcation Part (CAP) supporting the fourth phase of the network feature 
Customized AppHcations for Mobile network Enhanced Logic for IP Multimedia CN subsystems. CAP is based on a 
sub-set of the ETSI Core INAP CS-2 as specified by EN 301 140-1 [4]. Descriptions and definitions provided by 
EN 301 140-1 [4] are directly referenced by this standard in case no additions or clarifications are needed for the use in 
the CAP. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] ETSI ETS 300 287-1: "Integrated Services Digital Network (ISDN); Signalling System No.7; 
Transaction Capabilities (TC) version 2; Part 1 : Protocol specification [ITU-T Recommendations 
Q.771 to Q.775 (1993), modified]". 

[2] ETSI EN 300 356-1: "Integrated Services Digital Network (ISDN); SignalUng System No.7; ISDN 

User Part (ISUP) version 3 for the international interface; Part 1: Basic services 
[ITU-T Recommendations Q.761 to Q.764 (1997), modified]". 

[3] ETSI ETS 300 374-1 :"Intelligent Network (IN); Intelligent Network Capability Set 1 (CS 1); Core 

Intelligent Network Application Protocol (INAP); Part 1: Protocol specification". 

[4] ETSI EN 301 140-5: "Intelligent Network (IN); Intelligent Network Application Protocol (INAP); 

Capability Set 2 (CS2); Part 1: Protocol Specification". 

[5] ITU-T Recommendation Q.763: "Formats and codes of the ISDN user part of Signalling System 

No.7". 

[6] ITU-T Recommendation X.880 I ISO/IEC 9072- 1 : "Information technology - Remote Operations: 

Concepts, model and notation". 

[7] ITU-T Recommendation Q.713: "Specifications of Signalling System No.7; SCCP formats and 

codes". 

[8] ITU-T Recommendation Q.773: "Specifications of Signalling System No.7; Transaction 

capabilities formats and encoding". 

[9] 3GPP TS 29.002: "Digital cellular telecommunications system (Phase 2+); Mobile Application 

Part (MAP) specification (3GPP TS 29.002) Rel-99". 

[10] 3GPP TS 23.278: " Customised Apphcations for Mobile network Enhanced Logic (CAMEL) 

Phase 4 - Stage 2 IM CN Interworking". 

[II] 3GPP TS 29.078: " Customised Apphcations for Mobile network Enhanced Logic (CAMEL) - 
Phase 3; CAMEL Application Part (CAP) Specification - Release 99". 



ETSI 



3GPP TS 29.278 version 5.0.0 Release 5 



ETSI TS 129 278 V5.0.0 (2002-09) 



2.1 Specifications used for IIVIPORTs for CAP 

Table 2.1.1 lists the modules from which CAP V4 imports for IM CN specific operations. For each module, the table 
indicates in which formal specification this module can be found. 

Table 2.1.1 : Module IMPORTS specifications 



Module Name 


Specification 


Ref 


CSI-DataTypes {itu-titu-t{0) identified-organization(4) etsi(O) mobileDomain(O) 
umts-network(l) modules(3) cs1-datatypes(2) version1(0)} 


ETS 300 374-1 


[3] 


CS2-datatypes {itu-t(O) identified-organization(4) etsi{0) mobileDomain(O) umts- 
network(1) modules{3) in-cs2-datatypes (0) version1(0)} 


EN 301 140-1 


[4] 


MAP-CommonDatalypes {itu-t{0) identified-organization(4) etsi{0) 
mobileDomain(O) gsm-Network{1) modules{3) nnap-ConnmonDataTypes{18) 
version6{6)} 


3GPP TS 29.002 


[9] 


MAP-MS-Datalypes {itu-t(O) identified-organization{4) etsi(O) mobileDomain(O) 
gsm-Network(l) modules(3) map-MS-DataTypes(11) version6(6)} 


3GPP TS 29.002 


[9] 


MAP-CH-Datalypes {itu-t(O) identified-organization(4) etsi(O) mobileDomain{0) 
gsm-Network{1) modules(3) map-CH-DataTypes(13) version6(6)} 


3GPP TS 29.002 


[9] 


MAP-ExtensionDatalypes {itu-t(O) identified-organization{4) etsi{0) 
mobileDomain(O) gsm-Network{1) modules{3) map-ExtensionDataTypes(21) 
version6(6)} 


3GPP TS 29.002 


[9] 


TCAPMessages {itu-t recommendation q 773 modules(2) messages(1) 
version3{3)} 


ITU-T 0.773 


[8] 


Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) 
informationObjects(5) versioni (0)} 


ITU-T X.880 


[6] 


TC-Notation-Extensions {itu-t recommendation q 775 modules{2) notation- 
extension (4) versioni (1)} 


ETS 300 287-1 


[1] 


CAP-operationcodes {itu-t(O) identified-organization(4) etsi(O) mobileDomain(O) 
umts-network(l) modules(3) cap-operationcodes(53) version3(2)} 


3GPP TS 29.078 
Rel-99 


[11] 


CAP-datatypes {itu-t(O) identified-organization(4) etsi(O) mobileDomain(O) umts- 
network(1) modules{3) cap-datatypes(52) version3(2)} 


3GPP TS 29.078 
Rel-99 


[11] 


CAP-errortypes {itu-t(O) identified-organization{4) etsi(O) mobileDomain(O) umts- 
network(1) modules{3) cap-errortypes(51) version3(2)} 


3GPP TS 29.078 
Rel-99 


[11] 


CAP-errorcodes {itu-t(O) identified-organization(4) etsi{0) mobileDomain{0) umts- 
network(1) modules(3) cap-errorcodes(57) version3(2)} 


3GPP TS 29.078 
Rel-99 


[11] 


CAP-classes {itu-t{0) identified-organization(4) etsi{0) mobileDomain{0) umts- 
network(1) modules(3) cap-classes{54) version3(2)} 


3GPP TS 29.078 
Rel-99 


[11] 


CAP-object-identifiers {itu-t{0) identified-organization(4) etsi(O) 
mobileDomain{0)umts-network(1 ) modules{3) cap-object-identifiers(1 00) 
version3(2)} 


3GPP TS 29.078 
Rel-99 


[11] 





Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AC Application Context 

ASN. 1 Abstract Syntax Notation One 

BCSM Basic Call State Model 

CAP CAMEL Application Part 

CSl Capability Set 1 

CS2 CapabiHty Set 2 

CSI CAMEL Subscription Information 

DP Detection Point 

EDP Event Detection Point 

EDP-N Event Detection Point - Notification 

EDP-R Event Detection Point - Request 

FE Functional Entity 

FSM Finite State Model 

gsmSCF Service Control Function 

gsmSRF GSM Specialized Resource Function 

GT Global Title 
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ID IDentifier 

IN Intelligent Network 

IMS IP Multimedia Subsystems 

IM-SSF IP Multimedia Subsystem SSF 

IP Internet Protocol 

IP Intelligent Peripheral 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

MRFC Multimedia Resource Function Controller 

MSC Mobile services Switching Centre 

NA North American 

O-IM-BCSM Originating CAMEL BCSM for IMS 

PDU Protocol Data Unit 

PIC Point In Call 

PLMN Public Land Mobile Network 

ROS Remote Operations Service 

ROSE ROS Element 

RRB Request Report BCSM Event 

SSF Service Switching Function 

SCCP Signalling Connection Control Part 

SCP Service Control Point 

SDL System Description Language 

SLP Service Logic Program 

SS7 Signalling System no. 7 

SSME IM-SSF Management Entity 

SSP Service Switching Point 

TC Transaction Capabilities 

TCAP Transaction Capabilities Application Part 

TDP Trigger Detection Point 

TDP-R Trigger Detection Point - Request 

T-IM-BCSM Terminating CAMEL BCSM for IMS 



Introduction 



The CAP stage 3 specification for IMS re-uses the ASN.l definitions of CAP version 3 as specified in 3GPP Rel-99 TS 
29.078 with modifications for CAMEL/IMS interworking. A new Application Context has been created for IMS for 
Release 5. 

For general specifications including lower layer services (i.e. TC and SCCP procedures) , refer to specifications found 
in 3GPP TS 29.078 [11]. 

For IMS, the MRFC plays the role of a gsmSRF. The CAP operations sent between the gsmSCF and the gsmSRF are 
sent via the IM-SSF. The IM-SSF shall map the CAP operations intended for the gsmSRF into a SIP based protocol 
and sent to the gsmSRF via the S-CSCF. Standardization of the MRFC interface via S-CSCF is outside the scope of this 
specification. 



CAP Types for CAMEL/IMS interworking 



5.1 Datatypes 



CAP-IMS-datatypes (itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) umts-network ( 1 ) 

modules (3) cap-IMS-datatypes (62) versionl(O)} 

— This module contains the data type definitions used for CAMEL/IMS interworking. 



DEFINITIONS IMPLICIT TAGS 



BEGIN 



CldClgPartyURL (IMS-PARAMETERS-BOUND : imsBound} ::= OCTET STRING (SIZE( 
imsBound. &minCldClgPartyURLLength . . imsBound. &maxCldClgPartyURLLength) ) 
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— Indicates the SIP URL identifying the called and calling party numbers. Refer to RFC2806[45] for 
encoding . 

MediaType ::= INTEGER 

— The valid values for Media Type are for further study. 

SIPCallld { IMS-PARAMETERS-BOUND : imsBound} ::= OCTET STRING (SIZE( 
imsBound. SminSipCallldLength .. imsBound. SmaxSipCallldLength) ) 



END 



5.2 



Classes 



CAP-IMS-classes (itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) umts-network (1) 

modules (3) cap-IMS-classes (64) versionl(O)} 

— This module contains the class definitions used specifically for CAMEL/IMS interworking. 



DEFINITIONS 
IMPORTS 



BEGIN 



IMSSF-gsmSCF-Protocol, 
FROM CAP-IMS-object-identifiers {iut-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) 
umts-network ( 1 ) modules (3) cap-IMS-object-identifiers (100) versionl(O)} 

capImssfToScf Generic, 
FROM CAP-IMSSF-gsmSCF-pkgs-contracts-acs IMSSF-gsmSCF-Protocol 



IMS-PARAMETERS-BOUND 



CLASS 



SminCldClgPartyURLLength 
SmaxCldClgPartyURLLength 
SminSipCallldLength 
&maxSipCallIdLength 



INTEGER, 
INTEGER, 
INTEGER, 
INTEGER 



WITH SYNTAX 



MINIMUM-FOR-CLDCLG-PARTY-URL 
MAXIMUM-FOR-CLDCLG-PARTY-URL 
MINIMUM-FOR-S IP-CALL- ID 
MAXIMUM-FOR-SIP-CALL-ID 



SminCldClgPartyURLLength 
SmaxCldClgPartyURLLength 
SminSipCallldLength 
SmaxSipCallldLength 



ims-CAPSpecificBoundSet IMS-PARAMETERS-BOUND ::= 

{ 

MINIMUM-FOR-CLDCLG-PARTY_URL 1 

MAXIMUM-FOR-CLDCLG-PARTY_URL 100 

MINIMUM-FOR-SIP-CALL-ID 1 

MAXIMUM-FOR-SIP-CALL-ID 30 



END 



5.3 Object IDentifiers (IDs) 

CAP-IMS-object-identifiers (itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) 
umts-network ( 1 ) modules (3) cap-IMS-ob ject-identif iers ( 110 ) versionl(O)} 

DEFINITIONS ::= BEGIN 

— This module assigns new object identifiers for Modules, Packages, Contracts and AG's 

— used by CAP for IMS. 

IMSdatatypes OBJECT IDENTIFIER ::= 

(itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) umts-network ( 1 ) modules (3) 
cap-IMS-datatypes (52) versionl (0) } 

iMSclasses OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) umts-network (1) modules (3) 
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CAP-IMS-classes (54) versionl(O)} 

iMSSF-gsmSCF-Operations OBJECT IDENTIFIER ::= 

(itu-t{0) identif ied-organization (4 ) etsi(O) mobileDomain (0) umts-network (1) modules (3) 
cap-IMSSF-gsmSCF-ops-args (101) versionl (0) } 

IMSSF-gsmSCF-Protocol OBJECT IDENTIFIER ::= 

{itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) umts-network (1) modules (3) 

cap-IMSSF-gsmSCF-pkgs-contracts-acs (102) versionl (0) } 
id-CAPIOE OBJECT IDENTIFIER ::= 

(itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) umts-network (1) capImsOE (25) } 

id-acIE OBJECT IDENTIFIER ::= (id-CAPIOE ac(3)} 

id-contractlE OBJECT IDENTIFIER ::= (id-CAPIOE contract (26) } 

— IM-SSF/gsmSCF AC 

id-ac-CAP-IMSSF-scfCenericAC OBJECT IDENTIFIER ::= (id-acIE 4} 

— IM-SSF/gsmSCF Contracts 

id-CAPImssfToScfCeneric OBJECT IDENTIFIER ::= ( id-contract IE 3} 

END 



6 IP Multimedia Subsystem Call Control 

6.1 IM-SSF - gsmSCF Interface 



6.1 .1 Operations and arguments 



CAP-IMSSF-gsmSCF-ops-args (itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
umts-network ( 1 ) modules (3) cap-IMSSF-gsmSCF-ops-args ( 111 ) versionl (0)} 

DEFINITIONS IMPLICIT TAGS ::= BEGIN 

— This module contains the operations and operation arguments used for the 

— IM-SSF - gsmSCF interface, for the control of IP Multimedia call sessions. 

— Table 2.1.1 lists the specifications that contain the modules used by CAP. 
IMPORTS 

errortypes, 

datatypes, 

operationcodes, 

classes, 

tc-Messages, 

ros-InformationOb jects 
FROM CAP-ob ject-identif iers (itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) 
umts-network ( 1 ) modules (3) cap-object-identifiers (100) version3(2)} 

IMSdatatypes, 

iMSclasses, 
FROM CAP-IMS-object-identifiers (itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
umts-network ( 1 ) modules (3) cap-IMS-object-identifiers (110) versionl (0)} 

OPERATION 
FROM Remote-Operations-Informat ion-Ob jects ros-InformationOb jects 

CallingPartysCategory, 

HighLayerCompatibility, 

Redirect ion Information, 

ServiceKey 
FROM CSl-DataTypes (itu-t(O) identif ied-organization (4 ) etsi(O) inDomain(l) in-network ( 1 ) 
modules (0) csl-datatypes (2) versionl (0)} 

MiscCalllnfo 
FROM CS2-datatypes (itu-t(O) identif ied-organization (4) etsi(O) inDomain(l) in-network (1) 
cs2(20) modules (0) in-cs2-datatypes (0) versionl (0)} 

Ext-BasicServiceCode, 

IMSI, 

ISDN-Address St ring 
FROM MAP-CommonDataTypes (itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) 
gsm-Network (1) modules (3) map-CommonDataTypes (18) version6(6)} 

CUG-Index, 
CUG-Interlock, 
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CUG-Info, 

Location Information^ 

Subscriber St ate 
FROM MAP-MS-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
gsm-Network (1) modules (3) map-MS-DataTypes (11) version6(6)} 

CallRef erenceNumber, 

SuppressionOf Announcement 
FROM lyiAP-CH-DataTypes {itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
gsm-Network ( 1 ) modules (3) map-CH-DataTypes (13) version6(6)} 

PARAMETERS-BOUND 
FROM CAP-classes classes 

IMS-PARAMETERS-BOUND 
FROM CAP-IMS-classes iMSclasses 

opcode-act ivityTest, 
opcode-apply Charging, 
opcode-applyChargingReport, 
opcode-callGap, 
opcode-call InformationReport, 
opcode-call InformationRequest, 
opcode-cancel, 
opcode-connect , 
opcode- connectToRe source, 
opcode- continue, 
opcode-continueWithArgument , 
opcode-disconnectForwardConnection, 
opcode-eventReportBCSM, 
opcode- furnishCharging Information, 
opcode- initialDP, 
opcode- re leas eCall, 
opcode- requestReportBCSME vent, 
opcode-reset Timer, 
FROM CAP-operationcodes operationcodes 

AChBillingChargingCharacteristics ( } , 

AdditionalCallingPartyNumber {}, 

Alert ingPattern, 

AssistingSSPIPRoutingAddress {}, 

BCSMEvent, 

BearerCapability {}, 

CalledPartyNumber {}, 

CalledPartyBCDNumber {}, 

CallingPartyNumber ( } , 

CallResult {}, 

Carrier, 

Cause { } , 

CGEncountered, 

ChargeNumber { } , 

ControlType, 

CorrelationID { } , 

DestinationRoutingAddress (}, 

EventSpecif icInformationBCSM {}, 

EventTypeBCSM, 

Extensions { } , 

FCIBillingChargingCharacteristics ( } , 

GapCriteria { } , 

Gaplndicators, 

GapTreatment, 

GenericNumbers ( } , 

InvokelD, 

IPRoutingAddress { } , 

IPSSPCapabilities {}, 

legl, 

LocationNumber (}, 

MonitorMode, 

NAOlilnfo, 

OCSIApplicable, 

OriginalCalledPartylD {}, 

ReceivingSidelD, 

RedirectingPartylD {}, 

RequestedlnformationList {}, 

Request edInformationTypeList, 

ScfID {}, 

SCIBillingChargingCharacteristics ( } , 

SendingSidelD, 

Service Interactionlndicat or sTwo, 

TimeAndTimezone {}, 

TimerlD, 

TimerValue 
FROM CAP-datatypes {itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain ( ) umts-network ( 1 ) 
modules (3) cap-datatypes (52) version3(2)} 

CalledPartyURL {}, 
CallingPartyURL {}, 
MediaType {}, 
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SIPCallld {}, 

OriginalCalledPartyURL {}, 
RedirectingPartyURL {}, 
DestinationRoutingAddressURL { } 
FROM CAP-IMS-datatypes cap-IMS-datatypes 

cancelFailed, 

eTCFailed, 

missingCustomerRecord, 

missingParameter, 

par ameterOut Of Range, 

request edInfoError, 

systemFailure, 

taskRefused, 

unexpectedComponent Sequence, 

unexpectedDataValue, 

unexpectedParameter, 

unknownLegID 
FROM CAP-errortypes {itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0) umts-network (1) 
modules (3) cap-errortypes (51) versions (2)} 



activityTest OPERATION ::= { 
RETURN RESULT TRUE 
CODE opcode-activityTest 
} 

— Direction: gsmSCF -> IM-SSF, Timer: T^^ 

— This operation is used to check for the continued existence of a relationship 

— between the gsmSCF andlM-SSF. If the relationship is 

— still in existence, then the IM-SSF will respond. If no reply is received, 

— then the gsmSCF will assume that the IM-SSF has failed 

— in some way. 

applyCharging (PARAMETERS-BOUND : bound} OPERATION ::= ( 
ARGUMENT ApplyChargingArg (bound} 
RETURN RESULT FALSE 
ERRORS (missingParameter | 

unexpectedComponentSequence I 

unexpectedParameter t 

unexpectedDataValue I 

parameterOutOfRange I 

systemFailure I 

taskRefused I 

unknownLegID } 
CODE opcode-applyCharging 

} 

— Direction: gsmSCF -> IM-SSF, Timer: T^j, 

— This operation is used for interacting from the gsmSCF with the IM-SSF charging mechanisms. 

— The ApplyChargingReport operation provides the feedback from the IM-SSF to the gsmSCF. 

ApplyChargingArg (PARAMETERS-BOUND : bound} ::= SEQUENCE ( 

aChBillingChargingCharacteristics [0] AChBillingChargingCharacteristics (bound}, 

partyToCharge [2] SendingSidelD DEFAULT sendingSidelD : legl, 

extensions [3] Extensions (bound} OPTIONAL, 



— The partyToCharge parameter indicates the party in the call to which the ApplyCharging operation 

— shall be applied. 

applyChargingReport (PARAMETERS-BOUND : bound} OPERATION ::= ( 
ARGUMENT ApplyChargingReportArg (bound} 
RETURN RESULT FALSE 
ERRORS (missingParameter 

unexpectedComponentSequence | 

unexpectedParameter 1 

unexpectedDataValue I 

parameterOutOfRange I 

systemFailure I 

taskRefused} 
CODE opcode-applyChargingReport 

} 

— Direction: IM-SSF -> gsmSCF, Timer: T^^,^ 

— This operation is used by the IM-SSF to report to the gsmSCF the occurrence of a 

— specific charging event as requested by the gsmSCF using the ApplyCharging operation. 

ApplyChargingReportArg (PARAMETERS-BOUND : bound} ::= CallResult (bound} 

calllnformationReport (PARAMETERS-BOUND : bound} OPERATION ::= ( 
ARGUMENT Callinf ormat lonReportArg (bound} 
RETURN RESULT FALSE 
ALWAYS RESPONDS FALSE 
CODE opcode-call I nf ormat ionReport 
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— Direction: IM-SSF -> gsmSCF, Timer: Td-cp 

— This operation is used to send specific call information for a single call party to the gsmSCF as 

— requested by the gsmSCF in a previous CalllnformationRequest . 

CalllnformationReportArg (PARAMETERS-BOUND : bound} ::= SEQUENCE { 

requestedlnformationList [0] RequestedlnformationList {bound}, 
extensions [2] Extensions {bound} OPTIONAL, 

leglD [3] ReceivingSidelD OPTIONAL, 



CalllnformationRequest {PARAMETERS-BOUND : bound} OPERATION 



ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 



CalllnformationRequestArg {bound} 
FALSE 

{missingParameter 1 
parameterOutOfRange I 
requestedlnfoError | 
systemFailure I 
taskRefused 1 

unexpectedComponentSequence I 
unexpectedDataValue I 
unexpectedParameter | 
unknownLegID } 
opcode- CalllnformationRequest 



— Direction: gsmSCF -> IM-SSF, Timer: T(,j^^„ 

— This operation is used to request the IM-SSF to record specific information about a single 

— call party and report it to the gsmSCF (with a Callinf ormationReport operation) . 



CalllnformationRequestArg {PARAMETERS-BOUND : bound} ::= SEQUENCE { 

requestedlnformationTypeList [0] RequestedlnformationTypeList, 
extensions [2] Extensions {bound} 

leglD [3] SendingSidelD 



OPTIONAL, 
OPTIONAL, 



OPTIONAL denotes network operator optional. 



cancel OPERATION 
ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 



CancelArg 
FALSE 

{cancelFailed I 
missingParameter | 
taskRefused} 
opcode- cancel 



— Direction: gsmSCF -> IM-SSF, Timer: T^^^^ 

— This operation cancels the correlated previous operation or all previous requests. 

— operations can be canceled: PlayAnnouncement, PromptAndCollectUserInf ormation . 



The following 



CancelArg : : 
invokelD 
allRequests 



CHOICE { 



[0] InvokelD, 
[1] NULL 



The InvokelD has the same value as that which was used for the operation to be cancelled. 



connect {PARAMETERS-BOUND : bound} OPERATION 



ARGUMENT 
RETURN RESULT 
ERRORS 



{ 



CODE 



ConnectArg {bound, imsBound} 
FALSE 

{missingParameter | 
parameterOutOfRange I 
systemFailure I 
taskRefused I 

unexpectedComponentSequence I 
unexpectedDataValue I 
unexpectedParameter} 
opcode -connect 



— Direction: gsmSCF-> IM-SSF, Timer: T^q^ 

— This operation is used to request the IM-SSF to perform the call processing actions 

— to route or forward a call to a specified destination. 



ConnectArg {PARAMETERS-BOUND : bound 
destinationRoutingAddress 
alertingPattern 
originalCalledPartylD 
extensions 
carrier 

callingPartys Category 
redirect ingParty ID 
redirect ion Information 
genericNumbers 

service Interactionlndicat or sTwo 
chargeNumber 
cug- Inter lock 
cug-OutgoingAccess 
suppressionOf Announcement 
oCSIApplicable 
naOliInf o 



, IMS-PARAMETERS-BOUND : imsBound } ::= SEQUENCE { 

[0] DestinationRoutingAddress {bound} OPTIONAL, 

[I] AlertingPattern OPTIONAL, 
[6] OriginalCalledPartylD {bound} OPTIONAL, 
[10] Extensions {bound} OPTIONAL, 

[II] Carrier {bound} OPTIONAL, 
[28] CallingPartysCategory OPTIONAL, 
[29] RedirectingPartylD {bound} OPTIONAL, 
[30] Redirectionlnformation OPTIONAL, 
[14] GenericNumbers {bound} OPTIONAL, 
[15] ServicelnteractionlndicatorsTwo OPTIONAL, 
[19] ChargeNumber {bound} OPTIONAL, 
[31] CUG-Interlock OPTIONAL, 
[32] NULL OPTIONAL, 
[55] SuppressionOfAnnouncement OPTIONAL, 
[56] OCSIApplicable OPTIONAL, 
[57] NAOlilnfo, OPTIONAL, 
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connectArgExtension 



[58] ConnectArgExtension (imsBound) 



OPTIONAL 



— The following parameters in ConnectArg are not use for IMS; 

— carrier 

alert ingPattern 

genericNumbers 

service Interactionlndicat or sTwo 

chargeNumber 

— cug-Interlock 
cug-OutgoingAccess 

— suppressionOf Announcement 
oCSIApplicable 

— naOlilnfo 

ConnectArgExtension {IMS-PARAMETERS-BOUND : imsBound} ::= SEQUENCE { 

destinationRoutingAddressURL [0] CldClgPartyURL {imsBound} OPTIONAL, 

originalCalledPartyURL [1] CldClgPartyURL{ imsBound} OPTIONAL, 

redirectingPartyURL [2] CldClgPartyURL {imsBound} OPTIONAL, 



connectToResource {PARAMETERS-BOUND : bound} OPERATION 
RETURN RESULT FALSE 
ALWAYS RESPONDS FALSE 



CODE 



opcode- connectToResource 



— Direction: gsmSCF ->IM-SSF, Timer: T^tr 

— This operation is used to connect a call from the IM-SSF to the MRFC via S-CSCF . 

— Refer to clause 9 for a description of the procedures associated with this operation. 

continue OPERATION ::= { 
RETURN RESULT FALSE 
ALWAYS RESPONDS FALSE 
CODE opcode-continue 

} 

— Direction: gsmSCF -> IM-SSF, Timer: T^ue 

— This operation is used to request the IM-SSF to proceed with call processing at the 

— DP at which it previously suspended call processing to await gsmSCF instructions 

— (i.e. proceed to the next point in call in the BCSM) . The IM-SSF continues call 

— processing without substituting new data from gsmSCF. 



continueWithArgument {PARAMETERS-BOUND : bound} OPERATION 



ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 



ContinueWithArgumentArg {bound} 
FALSE 

{missingParameter | 
parameterOutOfRange I 
unexpectedComponentSequence I 
unexpectedDataValue I 
unexpectedParameter } 
opcode- continueWithArgument 



— Direction: gsmSCF -> IM-SSF, Timer: iQ^g, 

— This operation is used to request the IM-SSF to proceed with call processing at the 

— DP at which it previously suspended call processing to await gsmSCF instructions 

— (i.e. proceed to the next point in call in the BCSM) . The IM-SSF continues call 

— processing with the modified call setup information as received from the gsmSCF. 



ContinueWithArgumentArg {PARAMETERS- 
alert ingPattern 
extensions 

servicelnteractionlndicatorsTwo 
callingPartys Category 
genericNumbers 
cug-Interlock 
cug-OutgoingAccess 
chargeNumber 
carrier 

suppressionOf Announcement 
naOliInf o 



BOUND : bound} ::= SEQUENCE { 
[1] AlertingPattern 
[6] Extensions {bound} 
[7] Service Interactionlndicat or sTwo 
[12] CallingPartysCategory 
[16] GenericNumbers {bound} 
[17] CUG-Interlock 
[18] NULL 

[50] ChargeNumber {bound} 
[52] Carrier {bound} 
[55] SuppressionOf Announcement 
[56] NAOlilnfo, 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



— The following parameters in ConnectArg are not use for IMS: 

— carrier 

— alertingPattern 

— genericNumbers 

— service Interactionlndicat or sTwo 

— chargeNumber 

— cug-Interlock 
cug-OutgoingAccess 

— suppressionOf Announcement 
naOlilnfo 
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dis connect ForwardConnect ion OPERATION 
RETURN RESULT FALSE 



CODE 



{ systemFailure I 
taskRefused I 

unexpectedComponentSequence } 
opcode-disconnect ForwardConnect ion 



— Direction: gsmSCF -> IM-SSF, Timer: T^f^, 

— This operation is used to disconnect a connection to a 

— resource. Refer to clause 9 for a description of the procedures associated with this operation. 



eventReportBCSM (PARAMETERS-BOUND : bound} OPERATION ::= { 
ARGUMENT EventReportBCSMArg {bound} 
RETURN RESULT FALSE 
ALWAYS RESPONDS FALSE 

CODE opcode-eventReportBCSM 

} 

— Direction: IM-SSF -> gsmSCF, Timer: T^^j^ 

— This operation is used to notify the gsmSCF of a call-related event (e.g. BCSM 

— events such as busy or no answer) previously requested by the gsmSCF in a 

— RequestReportBCSMEvent operation. 



EventReportBCSMArg (PARAMETERS-BOUND : bound} 



SEQUENCE 



eventTypeBCSM 

event Specific InformationBCSM 

leglD 

miscCalllnfo 

extensions 



[0] EventTypeBCSM, 

[2] EventSpecificInformationBCSM {bound} OPTIONAL, 

[3] ReceivingSidelD OPTIONAL, 

[4] MiscCalllnfo DEFAULT {messageType request} 

[5] Extensions {bound} OPTIONAL, 



furnishCharginglnformation {PARAMETERS-BOUND : bound} OPERATION 



ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 



FurnishChargingInf ormationArg {bound} 

FALSE 

{missingParameter | 

taskRefused I 

unexpectedComponentSequence I 

unexpectedDataValue I 

unexpectedParameter } 

opcode- furnishCharginglnformation 



— Direction: gsmSCF -> IM-SSF, Timer: T^ ■ 

— This operation is used to request the IM-SSF to generate, register a call record 

— or to include some information in the default call record. 

— The registered call record is intended for off line charging of the call. 



FurnishChargingInf ormationArg {PARAMETERS-BOUND 
FCIBillingChargingCharact eristics {bound} 



bound} 



initialDP {PARAMETERS-BOUND : bound, IMS-PARAMETERS-BOUND : imsBound} OPERATION 



ARGUMENT 
RETURN RESULT 
ERRORS 



CODE 



InitialDPArg {bound, imsBound} 
FALSE 

{missingCustomerRecord I 
missingParameter 1 
parameterOutOfRange I 
systemFailure t 
taskRefused I 

unexpectedComponentSequence I 
unexpectedDataValue I 
unexpectedParameter} 
opcode-initialDP 



— Direction: gsmSSF -> gsmSCF, Timer: T^^p 

-- This operation is used after a TDP to indicate request for service. 



InitialDPArg {PARAMETERS-BOUND : bound, IMS- 

serviceKey [0] 

calledPartyNumber [2] 

callingPartyNumber [3] 

callingPartysCategory [5] 

cGEncountered [7] 

iPSSPCapabilities [8] 

locationNumber [10] 

originalCalledPartylD [12] 

extensions [15] 

highLayerCompatibility [23] 

additionalCallingPartyNumber [25] 

bearerCapability [27] 

eventTypeBCSM [28] 

redirectingPartylD [29] 

redirectionlnformation [30] 

cause [17] 

service Interactionlndicat or sTwo [32 ] 

carrier [37] 

cug-Index [45] 

cug-Interlock [46] 



PARAMETERS-BOUND : imsBound} 
ServiceKey , 
CalledPartyNumber {bound} 
CallingPartyNumber {bound} 
CallingPartysCategory 
CGEncountered 
IPSSPCapabilities {bound} 

LocationNumber {bound} 

OriginalCalledPartylD {bound} 

Extensions {bound} 

HighLayerCompatibility OPTIONAL, 

AdditionalCallingPartyNumber {bound} 

BearerCapability {bound} 

EventTypeBCSM 

RedirectingPartylD {bound} 

Redirectionlnformation 

Cause {bound} 

Service Interactionlndicat or sTwo 

Carrier {bound} 

CUG-Index 

CUG-Interlock 



SEQUENCE { 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 

OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
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cug-OutgoingAccess 

IMS I 

subscriber St ate 

locationlnformation 

ext-basicServiceCode 

callReferenceNumber 

iMSSFAddress 

calledPartyBCDNumber 

timeAndTimezone 

gsm-ForwardingPending 

initialDPArgExtension 



} 



[47] NULL 

[50] IMSI 

[51] SubscriberState 

[52] Locationlnformation 

[53] Ext-BasicServiceCode 

[54] CallReferenceNumber 

[55] ISDN-AddressString 

[56] CalledPartyBCDNumber {bound} 

[57] TimeAndTimezone {bound} 

[58] NULL 

[59] InitialDPArgExtension {imsBound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



The following parameters in InitialDPArg are not used for IMS; 
locationNumber 
highLayerCompatibility 
additionalCallingPartyNumber 
bearerCapability 
servicelnteractionlndicatorsTwo 
carrier 
cug-Index 
cug-Interlock 
cug-OutgoingAccess 
locationlnformation 
ext-basicServiceCode 
callReferenceNumber, 
calledPartyBCDNumber 
gsm-ForwardingPending 



InitialDPArgExtension 



{ IMS-PARAMETERS-BOUND 



imsBound} 



SEQUENCE { 



gmscAddress 

mediaType 

sipCallld 

calledPartyURL 

callingPartyURL 

originalCalledPartyURL 

redirect ingPartyURL 



[0] ISDN-AddressString 

[1] MediaType 

[2] SIPCallld {imsBound} 

[3] CldClgPartryURL {imsBound} 

[4] CldClgPartryURL {imsBound} 

[5] CldClgPartryURL {imsBound} 

[6] CldClgPartryURL {imsBound} 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



— The gmscAddress parameter in InitialDPArgExtension is not used for IMS. 

releaseCall {PARAMETERS-BOUND : bound} OPERATION ::= { 
ARGUMENT ReleaseCallArg {bound} 
RETURN RESULT FALSE 
ALWAYS RESPONDS FALSE 
CODE opcode-releaseCall 

} 

— Direction: gsmSCF -> IM-SSF, Timer: Tj,(, 

— This operation is used to tear down an existing call at any phase of the call for all parties 

— involved in the call. 

ReleaseCallArg {PARAMETERS-BOUND : bound} ::= Cause {bound} 

— A default value of decimal 31 (normal unspecified) shall be given. 

requestReportBCSMEvent {PARAMETERS-BOUND : bound} OPERATION ::= { 
ARGUMENT RequestReportBCSMEventArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 

parameterOutOfRange I 

systemFailure I 

taskRefused I 

unexpectedComponentSequence | 

unexpectedDataValue t 

unexpectedParameter 

unknownLegID } 
CODE opcode- requestReportBCSMEvent 

} 

— Direction: gsmSCF -> IM-SSF, Timer: T^^j^ 

— This operation is used to request the IM-SSF to monitor for a call-related event 

— (e.g. BCSM events such as busy or no answer), then send a notification back to the gsmSCF when 

— the event is detected. 

— NOTE: 

— Every EDP must be explicitly armed by the gsmSCF via a RequestReportBCSMEvent operation. 
No implicit arming of EDPs at the IM-SSF after reception of any operation (different 
from RequestReportBCSMEvent) from the gsmSCF is allowed. 

RequestReportBCSMEventArg {PARAMETERS-BOUND : bound} ::= SEQUENCE { 

bcsmEvents [0] SEQUENCE SIZE ( 1 .. bound. SnumOfBCSMEvents ) OF BCSMEvent, 
extensions [2] Extensions {bound} OPTIONAL, 

} 

— Indicates the BCSM related events for notification. 

resetTimer {PARAMETERS-BOUND : bound} OPERATION ::= { 
ARGUMENT ResetTimerArg {bound} 
RETURN RESULT FALSE 
ERRORS {missingParameter | 
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CODE 



parameterOutOfRange I 
taskRefused I 

unexpectedComponentSequence I 
unexpectedDataValue I 
unexpectedParameter } 
opcode-reset Timer 



— Direction: gsmSCF -> IM-SSF, Timer: T^^ 

— This operation is used to request the IM-SSF to refresh an application timer in the IM-SSF. 

ResetTimerArg (PARAMETERS-BOUND : bound} ::= SEQUENCE { 
timerlD [0] TimerlD DEFAULT tssf, 

timervalue [1] TimerValue, 
extensions [2] Extensions {bound} OPTIONAL, 



The following value ranges apply for operation specific timers in CAP: 



short: 

medium: 

long: 



1 s- 10 s 
1 s - 60 s 
1 s - 30 minutes 



Table 6.1.1.1 lists all operation timers and the value range for each timer. The definitive value for each operation timer 
may be network specific and has to be defined by the network operator. 

Table 6.1 .1 .1 : Timer value ranges 



Operation Name 


Timer 


Value range 


ActivityTest 


Tat 


short 


ApplyCharging 


Tac 


short 


ApplyChargingReport 


^acr 


short 


CalllnformationReport 


^cirp 


short 


CalllnformationRequest 


^cirq 


short 


Cancel 


^can 


short 


CallGap 


Teg 


short 


Connect 


Tcon 


short 


ConnectToResource 


Tctr 


short 


Continue 


Tcue 


short 


ContinueWithArgument 


Tcwa 


short 


DisconnectForwardConnection 


Tdfc 


short 


EventReportBCSM 


Terb 


short 


FurnishCharginglnformation 


Tfci 


short 


InitialDP 


Tjdp 


short 


ReleaseCall 


Trc 


short 


RequestReportBCSMEvent 


Trrb 


short 


ResetTimer 


Trt 


short 



6.1 .2 IM-SSF/gsmSCF packages, contracts and AGs 



6.1.2.1 IM-SSF/gsmSCF ASN.1 module 



CAP-IMSSF-gsmSCF-pkgs-contracts-acs ( itu-t ( ) identif ied-organization (4 ) etsi ( ) mobileDomain (0 ) 
umts-network (1) modules (3) cap-IMSSF-gsmSCF-pkgs-contracts-acs (112) versionl (0) } 



DEFINITIONS 



BEGIN 



— This module specifies the Operation Packages, Contracts, Application Contexts 

— and Abstract Syntaxes used for the IM-SSF - gsmSCF interface used for the control of 

— IP Multimedica call sessions . 

— Table 2.1.1 lists the specifications that contain the modules used by CAP. 
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IMPORTS 

PARAMETERS-BOUND, 
CAPSpecificBoundSet 
FROM CAP-classes classes 

IMS-PARAMETERS-BOUND 
FROM CAP-IMS-classes IMSclasses 

CONTRACT, 

OPERAT ION-PACKAGE , 
OPERATION 
FROM Remote-Ope rat ions -Information-Objects ros-Inf ormationOb jects 

TCMessage {} 
FROM TCAPMessages tc-Messages 

APPLICATION-CONTEXT, 
dialogue-abstract-syntax 
FROM TC-Notation-Extensions tc-NotationExtensions 

activityTest, 
applyCharging { } , 
applyChargingReport {}, 
callGap {}, 

calllnformationReport {}, 
calllnformationRequest {}, 
cancel , 
connect { } , 
connectToResource {}, 
continue, 

continueWithArgument (}, 
dis connect ForwardConnect ion, 
eventReportBCSM { } , 
furnishChargingInf ormation (}, 
initialDP {}, 
releaseCall { } , 
requestReportBCSMEvent {}, 
resetTimer { } 
FROM CAP-IMSSF-gsmSCF-ops-args iMSSF-gsmSCF-Operations 

playAnnouncement { } , 
promptAndCollectUserlnformation { } , 
special izedRe sour ceReport 
FROM CAP-gsmSCF-gsmSRF-ops-args gsmSCF-gsmSRF-Operations 

specializedResourceControlPackage ( } 
FROM CAP-gsmSCF-gsmSRF-pkgs-contracts-acs gsmSCF-gsmSRF-Protocol 

id-as-gsmSSF-scf GenericAS, 

id-package- scfActi vat ion, 

id-package-gene ricD is connect Re source, 

id-package-nonAssistedConnectionEstablishment , 

id-package-connect , 

id-package-callHandling, 

id-package-bcsmE vent Handling, 

id-package-ssfCallProcessing, 

id-package-timer, 

id-package-billing, 

id-package-charging, 

id-package-traf f icManagement, 

id-package-callReport, 

id-package-signallingControl, 

id-package-act ivityTest, 

id-package- cancel, 

classes, 

ros-Inf ormationOb jects, 

tc-Messages, 

tc-NotationExtensions, 

gsmSCF-gsmSRF-Ope rat ions, 

gsmSCF-gsmSRF-Protocol 
FROM CAP-ob ject-identif iers (itu-t(O) identif ied-organization (4 ) etsi(O) mobileDomain (0 ) 
umts-network ( 1 ) modules (3) cap-object-identifiers (100) versions (2)} 

id-ac-CAP-IMSSF-scfCenericAC, 

id-CAPImssfToScf Generic, 

IMSclasses, 

IMSSF-gsmSCF-Operations 
FROM CAP-IMS-object-identifiers {itu-t(O) identif ied-organization (4) etsi(O) mobileDomain (0) 
umts-network ( 1 ) modules (3) cap-IMS-ob ject-identif iers ( 110 ) version4(3)} 

— Application Contexts 

cap-IMSSF-scfGenericAC APPLICATION-CONTEXT ::= { 

CONTRACT capImssfToScfGeneric 

DIALOGUE MODE structured 

ABSTRACT SYNTAXES { dialogue-abstract-syntax \ 
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gsmSSF-scfGenericAbstract Syntax 
APPLICATION CONTEXT NAME id-ac-CAP-IMSSF-scf GenericAC } 



— Contracts 

capImssfToScfGenericCONTRACT ::= { 

— dialogue initiated by IM-SSF with InitialDP Operation 

INITIATOR CONSUMER OF 

( scf ActivationPackage ( cAPSpecif icBoundSet } } 
RESPONDER CONSUMER OF 

{activityTestPackage I 

bcsmEventHandlingPackage { cAPSpecif icBoundSet } I 

billingPackage {cAPSpecif icBoundSet } I 

callHandlingPackage (cAPSpecif icBoundSet } I 

callReportPackage { cAPSpecif icBoundSet } I 

cancelPackage t 

chargingPackage { cAPSpecif icBoundSet } I 

connectPackage {cAPSpecif icBoundSet } I 

gene ricD is connect Res our cePackage I 

nonAssistedConnectionEstablishmentPackage { cAPSpecif icBoundSet } I 

signallingControlPackage { cAPSpecif icBoundSet } 1 

specializedResourceControlPackage { cAPSpecif icBoundSet } I 

ssfCallProcessingPackage {cAPSpecif icBoundSet } 1 

timerPackage {cAPSpecif icBoundSet } I 

traf f icManagementPackage { cAPSpecif icBoundSet } } 
ID id-CAPImssfToScfCeneric 



— Operation Packages 

scfActivationPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES {initialDP {bound}} 

ID id-package-scfActivation} 
genericDisconnectResourcePackage OPERATION-PACKAGE ::= { 

CONSUMER INVOKES { disconnectForwardConnect ion } 

ID id-package-genericDisconnectResource } 
nonAssistedConnectionEstablishmentPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE 

CONSUMER INVOKES { connectToResource {bound}} 

ID id-package-nonAssistedConnectionEstablishment } 
connectPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES {connect {bound}} 

ID id-package-connect} 
callHandlingPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES {releaseCall {bound}} 

ID id-package-callHandling} 
bcsmEventHandlingPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES { requestReportBCSMEvent {bound}} 

SUPPLIER INVOKES { eventReportBCSM {bound}} 

ID id-package-bcsmEventHandling} 
ssfCallProcessingPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES { cont inueWithArgument {bound} t continue} 

ID id-package-ssfCallProcessing} 
timerPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES {resetTimer {bound}} 

ID id-package-timer} 
billingPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES { f urnishChargingInf ormat ion {bound}} 

ID id-package-billing} 
ChargingPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES { applyCharging {bound}} 

SUPPLIER INVOKES { applyChargingReport {bound}} 

ID id-package-charging} 
trafficManagementPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES {callGap {bound}} 

ID id-package-traf f icManagement } 
callReportPackage {PARAMETERS-BOUND : bound} OPERATION-PACKAGE ::= { 

CONSUMER INVOKES { callinf ormat ionRequest {bound}} 

SUPPLIER INVOKES { callinf ormat ionReport {bound}} 

ID id-package-callReport } 
activityTestPackage OPERATION-PACKAGE ::= { 

CONSUMER INVOKES { act ivityTest } 

ID id-package-activityTest } 

cancelPackage OPERATION-PACKAGE ::= { 

CONSUMER INVOKES {cancel } 

ID id-package-cancel} 



— Abstract Syntaxes 

gsmSSF-scfCenericAbstractSyntax ABSTRACT-SYNTAX ::= { 

GenericSSF-gsmSCF-PDUs 

IDENTIFIED BY id-as-gsmSSF-scf GenericAS } 
GenericSSF-gsmSCF-PDUs ::= TCMessage { { SsfToScfGenericInvokable} 

{SsfToScfGenericReturnable} } 
SsfToScfGenericInvokable OPERATION ::= { 
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activityTest I 

applyCharging { cAPSpecif icBoundSet } I 
applyChargingReport { cAPSpecif icBoundSet } I 
calllnformationReport { cAPSpecif icBoundSet } I 
calllnformationRequest { cAPSpecif icBoundSet } I 
cancel 1 

connect { cAPSpecif icBoundSet } I 
continueWithArgument {cAPSpecif icBoundSet } I 
connectToResource (cAPSpecif icBoundSet } I 
disconnectForwardConnection | 
eventReportBCSM {cAPSpecif icBoundSet } I 
furnishCharginglnformation (cAPSpecif icBoundSet } I 
initialDP { cAPSpecif icBoundSet } I 
releaseCall { cAPSpecif icBoundSet } I 
requestReportBCSMEvent (cAPSpecif icBoundSet } I 
resetTimer { cAPSpecif icBoundSet } I 
sendCharginglnformation (cAPSpecif icBoundSet } I 
playAnnouncement { cAPSpecif icBoundSet } I 
promptAndCollectUserlnformation { cAPSpecif icBoundSet } I 
special izedRe sour ceReport 



6.2 gsmSCF/gsmSRF interface 

ASN.l definitions used for the gsmSCF/gsmSRF interface are found in TS 29.078 [11]. 

7 Application Entity procedures 

The description of the application entity procedures for CAMEL Phase 4 for IP Multimedia call sessions can be found 
in 3GPPTS 23.278 [10]. 

8 Error procedures 

The description of the error procedures for CAMEL Phase 4 for IP Multimedia call sessions can be found in 3GPP TS 
29.078 [11]. 

9 Detailed operation procedures 

9.1 ActivityTest procedure 
9.1.1 General description 

This operation is used to check for the continued existence of a relationship between the gsmSCF and IM-SSF. If the 
relationship is still in existence, then the receiving entity will respond. If no reply is received within a given time period, 
then the gsmSCF which sent this operation will assume that the receiving entity has failed in some way and will take the 
appropriate action. 

9.1.1.1 Parameters 

None. 
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9.1 .2 Responding entity (IM-SSF) 

9.1.2.1 Normal procedure 

IM-SSF preconditions: 

(1) A relationship exists between the gsmSCF and the IM-SSF. 

(2) The SSME-FSM is in the state "Idle Management" or "Non-call Associated Treatment". 
IM-SSF postconditions: 

(1) The SSME-FSM stays in, or moves to the state "Non-call Associated Treatment". 

(2) If the Dialogue ID is active and there is a IM-SSF using the dialogue, then the SSME sends a Return Result 
"Activity Test" to the gsmSCF. If there are no other management activities (e.g. Call Gapping), then the 
SSME-FSM returns to the state "Idle Management". Otherwise, the SSME-FSM remains in the state "Non-call 
Associated Treatment". 

If the Dialogue ID is not active, then the TC in the IM-SSF will issue a P- Abort. The SSME will in that case 
not receive the "ActivityTest" indication and thus will not be able to reply. 

9.1.2.2 Error handling 

Operation related error handling is not applicable, due to class 3 operation. 

9.2 ApplyCliarging procedure 
9.2.1 General description 

This operation is used for interacting from the gsmSCF with the IM-SSF function: CSE control of call duration. The 
ApplyChargingReport operation provides the feedback from the IM-SSF to the gsmSCF. 

The charging scenarios supported by this operation are those given in 3GPP TS 22.078 for CSE control of call duration. 

9.2.1.1 Parameters 

aChBillingChargingCharacteristics: 

This parameter specifies a list of parameters required for CSE control of call duration: 

The list may contain: 

- timeDurationCharging: 

This list contains the following parameters: 

maxCallPeriodDuration: 

This parameter specifies the period of time for which a call can progress before an ApplyChargingReport 

shall be sent to the gsmSCF. 

releaselfdurationExceeded: 

This parameter specifies the action to be taken at the IM-SSF when the duration specified above has been 

reached. If the parameter is present, then the call is released. 

tone: 

If the parameter is present, then a warning tone is played when the warning tone timer expires. 

tariffSwitchlnterval: 

This parameter indicates to the IM-SSF the time duration until the next tariff switch. The measurement of the 

elapsed tariff switch period commences immediately upon successful execution of this operation. 
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partyToCharge: 

This parameter indicates the party in the call. 

9.2.2 Responding entity (IM-SSF) 

9.2.2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship exists between the gsmSCF and the IM-SSF. 

(2) The IM-SSF is in one of the following states: 

"Waiting for Instructions"; 

"Waiting for End of User Interaction"; 

"Monitoring". 
IM-SSF postcondition: 

(1) No FSM state transition. 

On receipt of this operation, the IM-SSF sets the charging data using the information elements included in the operation 
and acts accordingly. 

The IM-SSF will start monitoring for the Answer event upon receipt of the ApplyCharging operation if Answer has not 
already been received on an outgoing connection to a Called Party or a connection to the gsmSRF. Upon subsequent 
detection of the Answer event on the outgoing connection charging is started. If the Answer event has been received 
from an outgoing connection already when the ApplyCharging operation is received then charging starts immediately. 

Upon release of an outgoing connection to the Called Party or the gsmSRF connection any indication of Answer event 
receipt on the outgoing connection is cleared i.e. set to Answer event not received. 

9.2.2.2 Error handling 

TaskRefused: In addition to the generic error handling noted below, this error shall be indicated when: 

a previously received call period duration is pending; 

a tariffs witchlnterval is indicated when a previously received tariffs witchlnterval is pending. 

Generic error handling for the operation related errors is described in clause 8 and the TC services used for reporting 
operation errors are described in clause 12 in TS 29.078 [11]. 

9.3 ApplyChargingReport procedure 
9.3.1 General description 

This operation is used by the IM-SSF to report charging related information to the gsmSCF as requested by the gsmSCF 
using the "ApplyCharging" operation. 

Timing of duration shall be started if answer is detected by the IM-SSF. It shall be started independently for a 
connection to a Called Party and an gsmSRF connection. 

A report is generated as specified in the 3GPP TS 23.278 [10]. 

9.3.1.1 Parameters 

callResult: 

This parameter provides the gsmSCF with the charging related information previously requested using the 

ApplyCharging operation. The "CallResult" is a list, and can contain the following parameters: 
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timeDurationChargingResult: 

This is a list, and can contain the following parameters: 

timelnformation: 

This is a choice of the following parameters: 

timelfNoTariffSwitch: 

This parameter will be present if no tariff switch has occurred since the reception of the first 

ApplyCharging operation for the connection to the Called Party or gsmSRF connection, otherwise 

it will be absent. 

If Answer was detected for the connection to the Called Party or the gsmSRF connection, then the 

elapsed time since detection of Answer shall be reported. If answer was not detected, it shall be set 

to "0". 

timelfTariffSwitch: 

This parameter will be present if a tariff switch has occurred since the reception of the first 
ApplyCharging operation for the connection to the Called Party or gsmSRF connection, 
otherwise it will be absent. 
The parameter may contain the following information: 

timeSinceLastTariffS witch: 

If Answer was detected for the connection to the Called Party or the gsmSRF 
connection, then the elapsed time since detection of Answer or the last tariff switch 
(whichever of these events was last detected) shall be reported. If Answer was not 
detected, it shall be set to "0". 

TariffSwitchlnterval: 

This parameter is present only if a tariff switch has occurred since the detection of 

Answer for the connection to the Called Party or the gsmSRF connection in the reported 

call period. 

The time interval between either the detection of the Answer event or the previous tariff 

switch (whichever of these events was last detected) and the last tariff switch is 

reported. 

partyToCharge: 

The "partyToCharge" parameter as received in the related ApplyCharging operation or deduced from the 

default value, to correlate the result to the request. 

call Active: 

This parameter indicates whether the call is still active or has been released. 

callReleasedAtTcpExpiry: 

This parameter, if present, indicates that the IM-SSF has released the call and terminated the dialogue. 

It shall be present when ACR is sent due to Tcp expiry and the IM-SSF has released the call (because 

ReleaselfExceeded was present in ACH) and terminated the dialogue. 

In all other instances, this parameter shall be absent. 

9.3.2 Invoking entity (IM-SSF) 
9.3.2.1 Normal procedure 

IM-SSF preconditions: 

(1) A relationship exists between the IM-SSF and the gsmSCF. 

(2) A charging event has been detected that was requested by the gsmSCF via an ApplyCharging operation or a 
Called Party or gsmSRF disconnection event has occurred. 

IM-SSF postconditions: 
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(1) If release of the call has occurred because the allowed call duration has been reached: 

All outstanding EDPs shall be disarmed; 

ApplyChargingReport shall be sent to gsmSCF followed by any outstanding CalllnformationReports, 
if applicable; 

The IM-SSF shall transit to the Idle' state. 

(2) If release of the call has occurred but not because the allowed call duration has been reached: 

If there are any outstanding EDPs or other reports then the IM-SSF shall remain in the same state, else; 
The IM-SSF shall transit to the Idle' state. 
This operation is invoked if a charging event has been detected that was requested by the gsmSCF. 

9.3.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services used for reporting 
operation errors are described in TS 29.078 [11]. 

9.4 CallGap procedure 
9.4.1 General description 

This operation is used to request the IM-SSF to reduce the rate at which specific service requests are sent to the 
gsmSCF. For CAMEL, this operation could be sent only on a dialogue that has been opened by the IM-SSF by an 
InitialDP operation. 

9.4.1.1 Parameters 

gapCriteria: 

This parameter identifies the criteria for a call to be subject to call gapping. It consists of the following alternatives: 

basicGapCriteria or compoundGapCrteria: 

basicGapCriteria: 

This parameter consists of: 

calledAddressValue: 

This parameter indicates that call gapping shall be applied when the leading digits of the dialled number 
of a call attempt match those specified in "gapCriteria". The called address is the one received from the 
current call control. 

gapOnService: 

This parameter indicates that call gapping shall be applied when the "serviceKey" of a call attempt match 

those specified in "gapCriteria". 

calledAddressAndService: 

This parameter indicates that call gapping shall be applied when the "serviceKey" and the leading digits 
of the dialled number of a call attempt match those specified in "gapCriteria". The called address is the 
one received from the current call control. 

callingAddressAndService: 

This parameter indicates that call gapping shall be applied when the "serviceKey" and the leading digits 
of the calling party number of a call attempt match those specified in "gapCriteria". In the case of call 
forwarding the calling address to be gapped is the redirecting number which would be put in the Initial 
DP operation. 

compoundGapCriteria: 

This parameter consists of the foUlowing subparameters: 
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basicGapCriteria: 

This parameter is as described above. 

scflD: 

The means of identification of an gsmSCF. The scflD is to convey the necessary gsmSCF address 

information (e.g. Global Title) in the network to the requesting IM-SSF. See Q.713 "calling party address" 

parameter. The network operator has to decide about the actual mapping of this parameter on the used 

signalling system. 

This parameter indicates the address of the gsmSCF, which initiated the call gapping. 

When scflD is used in an operation, which may cross an internetwork boundary, its encoding must be 

understood in both networks; this requires bilateral agreement on the encoding. If this parameter is not 

available the call gapping is not dedicated to a specific gsmSCF. 

This subparameter is restricted to include a fixed GT address string. 

Note: In the case where the GT addresses more than one SCP (e.g. a mated pair) then if one of these physical 

SCPs enters overload conditions and issues CallGap, then it is applied to all of them. 

gaplndicators: 

This parameter indicates the gapping characteristics. 

duration: 

Duration specifies the total time interval during which call gapping for the specified gap criteria will be active. 

A duration of indicates that gapping is to be removed. 

A duration of -2 indicates a network specific duration. 

Other values indicate duration in seconds. A duration of -1 shall not be used. 

gaplnterval: 

This parameter specifies the minimum time between calls being allowed through. 

An interval of indicates that calls meeting the gap criteria are not to be rejected. 

An interval of -1 indicates that all calls meeting the gap criteria are to be rejected. 

Other values indicate interval in milliseconds. 

controlType: 

This parameter indicates the reason for activating call gapping. 

The "controlType" value "sCPOverloaded" indicates that an automatic congestion detection and control 
mechanism in the SCP has detected a congestion situation. 

The "controlType" value "manuallylnitiated" indicates that the service and or network/service management 
centre has detected a congestion situation, or any other situation that requires manually initiated controls. 

NOTE: The controlType 'manuallylnitiated' will have priority over 'sCPOverloaded' call gap. It should be noted 

that also non-IN controlled traffic control mechanism can apply to an exchange with the SSF functionality. 
The non-IN controlled traffic control may also have some influence to the IN call. Therefore it is 
recommended to take measures to co-ordinate several traffic control mechanisms. The non-IN controlled 
traffic control and co-ordination of several traffic control mechanisms are out of the scope of CAP. 

gapTreatment: 

This parameter indicates how calls that were stopped by the call gapping mechanism shall be treated. 

informationToSend: 

This parameter indicates an announcement or a tone to be sent to the calling party. At the end of 
information sending, the call shall be released. 

inbandlnfo: 

This parameter specifies the inband information to be sent. 

messagelD: 

This parameter indicates the message(s) to be sent, it can be one of the following: 
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elementaryMessagelD: 

This parameter indicates a single announcement. 

duration: 

This parameter indicates the maximum time duration in seconds that the message shall be 

played/repeated. ZERO indicates endless repetition. 

tone: 

This parameter specifies a tone to be sent to the end-user. 

tonelD: 

This parameter indicates the tone to be sent. 

duration: 

This parameter indicates the time duration in seconds of the tone to be sent. ZERO 

indicates infinite duration. 

releaseCause: 

If the call is to be released, this parameter indicates a specific cause value to be sent in the release 

message. See EN 300 356-1 [2]. 

9.4.2 Responding entity (IM-SSF) 
9.4.2.1 Normal procedure 

IM-SSF precondition: 

(1) Call gapping for gapCriteria is not active, or 
Call gapping for gapCriteria is active. 

(2) The IM-SSF is in any state except "Idle" and except "Wait_For_Request". 
IM-SSF postcondition: 

(1) The gsm_SSME_FSM process is in the state "Active". 

(2) Call gapping for gapCriteria is activated, or 
Call gapping for gapCriteria is renewed, or 
Call gapping for gapCriteria is removed. 

(3) The IM-SSF remains in the same state. 

If there is not already an existing gsm_SSME_FSM for the gap criteria and gsmSCFAddress provided, a new 
gsm_SSME_FSM is created. If no gsmSCFAddress is provided, this refers in general to the gsm_SSME_FSM without a 
gsmSCFAddress. This gsm_SSME_FSM enters the state "Active" and initializes call gapping for the specified IN calls. 
The parameters "gaplndicators", "controlType", "gap Treatment" and "gsmSCFAddress" for the indicated gap criteria 
will be set as provided by the "CallGap" operation. 

In the case both manually initiated and automatically initiated service request gapping are active for the same 
"gapCriteria", the manuallylnitiated call gapping prevails over automatically initiated ("sCPOverloaded"). More 
specifically, the following rules shall be applied in the SSF to manage the priority of different control Types associated 
with the same "gapCriteria": 

If a gsm-SSME-FSM already exists for the "gapCriteria" and the gsmSCFAddress provided, then: 

(1) if the (new) "controlType" equals an existing "controlType", then the new parameters 
(i.e., "gaplndicators" and "gap Treatment") overwrites the existing parameter values. 

(2) if the (new) "controlType" is different than the existing "controlType", then the new parameters (i.e., 
"controlType", "gaplndicators", and "gap Treatment") shall be appended to the appropriate 
gsm_SSME_FSM (in addition to the existing parameters). The gsm_SSME_FSM remains in the state 
"Active". 
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If the IM-SSF meets a TDP, it checks if call gapping was initiated for the same gsmSCF as the one currently assigned to 
this TDP or if call gapping exists with no provided gsmSCF Address. If neither call gapping was initiated nor exists, an 
"InitialDP" operation may be sent. 

It checks if call gapping was initiated either for the "serviceKey" or for the "calledAddressValue" assigned to this TDP. 
If not, an "InitialDP" operation may be sent. In the case call gapping was initiated for "calledAddressAndService" or 
"callingAddressAndService" and the "serviceKey" matches, a check on the "calledAddressValue" and 
"callingAddressValue" for active call gapping shall be performed. If not, an "InitialDP" operation may be sent. 

If a call to a controlled number matches only one "gapCriteria", then the corresponding control is applied. If both 
"manually Initiated" and "sCPOverload" controls are active, then only the manually initiated control shall be applied. 

If a call matches several active "basicGapCriteria", then the treatment as specified in the CallGap associated with the 
gapCriteria with the highest priority should be applied, with the priority being from high to low: 

1 . calledAddress AndService/calledAddressValue; 

2. callingAddressAndService; 

3. gapOnService. 

For example, a call with called number 123456 and ServiceKey = NP matches two CallGaps, one with gapCriteria 
'CalledAdressValue=123' and another with 'gapOnService=NP' . Then the call is subject to the control of the service 
request CallGap with 'CalledAdressValue=123'. 

In case multiple call gapping procedures are active with the same gap criteria, the "manuallylnitiated" call gapping shall 
prevail over automatically initiated service request gapping ("sCPOverloaded"). 

If a call to a controlled called number or from a controlled calling number matches several active "basicGapCriteria " of 
the same type (in this context 'calledAddressAndService' and 'calledAddressValue' are seen as one type), then only the 
"gapCriteria" associated with the longest called party number shall be used, and the corresponding control shall be 
applied. For example, the codes 1234 and 12345 are under control. Then the call with 123456 is subject to the control 
on 12345. 

If a call to a controlled called number matches calledAddressAndService and calledAddressValue with the same 
number length, than calledAddressAndService has priority. Furthermore, if both "manuallylnitiated" and 
"sCPOverloaded" "controlTypes" are active for this "gapCriteria", then the "manuallylnitiated" control shall be applied. 

If call gapping is performed on a call for a particular service and triggering of this service is allowed no other gap 
criteria should be applied to the same service. 

Active GapCriteria with assigned scfID will have higher priority than the others. In case an entry with scflD matching 
the current call exist all other criteria without scflD are not evaluated. 

The matching entries with scflD are evaluated in accordance with the priority rules for the basic criteria listed above. 

If call gapping shall be applied and there is no gap interval active, an "InitialDP" operation may be sent including the 
"cGEncountered" parameter according to the specified controlType. A new gap interval shall be initiated as indicated 
by "gaplnterval". 

If a gap interval is active, no "InitialDP" operation is sent and the call is treated as defined by Default Call Handling and 
"gapTreatment". 

The call gap process is stopped if the indicated duration equals ZERO. 

If call gapping proceeds then the gsm_SSME_FSM remains in the state "Active". Otherwise, the gsm_SSME_FSM 
moves to state "idle". 

9.4.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 
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9.5 CalllnformationReport procedure 

9.5.1 General description 

This operation is used to send specific call information for a single call party to the gsmSCF as requested by the 
gsmSCF in previous "CalllnformationRequest" operation. The report is sent at the end of a call party connection which 
is indicated by one of the events specified below. 

9.5.1.1 Parameters 

requestedlnformationList: 

According to the requested information the IM-SSF sends the appropriate types and values to the gsmSCF. 

leglD: 

This parameter indicates the party in the call for which the information has been collected. When absent, it 

indicates the "outgoing" leg, this can be a leg created by Connect/Continue/ContinueWithArgument. 

9.5.2 Involving entity (IM-SSF) 
9.5.2.1 Normal procedure 

IM-SSF precondition: 

(1) The indicated or default party is released from the call or call setup towards the indicated or default party is not 
completed. 

(2) Requested call information has been collected. 

(3) "CalllnformationReport" is pending due to a previously received "CalllnformationRequest" operation. 

(4) A control or a monitor relationship exists between the gsmSCF and the IM-SSF. 

IM-SSF postcondition: 

(1) The IM-SSF shall move to the "Idle" state in the case where no other report requests are pending and no EDPs 
are armed otherwise the IM-SSF FSM shall remain in the same state. 

If the IM-SSF FSM executes a state transition caused by one of the following events: 

release for the indicated or default leg; 

abandon for the indicated or default leg; 

Called party busy or Not Reachable for the indicated or default leg; 

IM-SSF no answer timer expiration for the indicated or default leg; 

route select failure for the indicated or default leg; 

release of call initiated by the gsmSCF (ReleaseCall), 

and "CalllnformationRequest" is pending for the indicated or default legs then one "CalllnformationReport" operation is 
sent to the gsmSCF containing all information requested for that leg. 

If a "CalllnformationReport" has been sent to the gsmSCF then no "CalllnformationReport" is pending on that leg, i.e. a 
further "CalllnformationReport" on that leg, for example in the case of follow-on, has to be explicitly requested by the 
gsmSCF. 

If an event causing the "CalllnformationReport" is also detected by an armed EDP-R then immediately after 
"CalllnformationReport" the corresponding "EventReportBCSM" has to be sent. 

If an event causing the "CalllnformationReport" is also detected by an armed EDP-N then immediately before 
"CalllnformationReport" the corresponding "EventReportBCSM" has to be sent. 
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9.5.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.6 CalllnformationRequest procedure 

9.6.1 General description 

This operation is used to request the IM-SSF to record specific information about a single call party and report it to the 
gsmSCF using the "CalllnformationReport" operation. 

9.6.1.1 Parameters 

requestedlnformationTypeList: 

This parameter specifies a list of specific items of information which is requested. 

The list may contain: 

callAttemptElapsedTime: 

This parameter indicates the duration between the end of CAP processing of operations initiating call 
setup ("Connect", "Continue" or "Continue WithArgument") and the received answer indication from 
called party side. For a calling party leg this parameter has to be set to 0. 

In case of unsuccessful call setup the network event indicating the unsuccessful call setup stops the 
measurement of "callAttemptElapsedTime". 

callStopTime: 

This parameter indicates the time stamp when the connection is released. 

callConnectedElapsedTime: 

This parameter indicates the duration between the received answer indication from the called party side 
and the release of that connection. For a calling party it indicates the duration between the sending of 
IDP and the release of that party. 

releaseCause: 

This parameter indicates the release cause for the call. 

leglD: 

This parameter indicates the party in the call for which the information shall be collected and at the end 
of connection of which the report shall be sent. When absent, it shall apply to the "outgoing" leg, this can 
be a leg created by Connect/Continue/Continue WithArgument. 

9.6.2 Responding entity (IM-SSF) 
9.6.2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship exists between IM-SSF and gsmSCF. 
IM-SSF postcondition: 

(1) Requested call information is retained by the IM-SSF. 

(2) The IM-SSF is waiting for further instructions. 

The IM-SSF may receive the "CalllnformationRequest" operation within an existing call associated (CA) dialogue only. 

The "CalllnformationRequest" operation is accepted by the IM-SSF Finite State Machine (IM-SSF-FSM) only in the 
state "Waiting for Instructions". The operation does not lead to any transition to another state. 
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The IM-SSF allocates a record for the indicated or default party and stores the requested information if already 
available and prepares the recording of information items, that will become available later like for example 
"callStopTimeValue". 

Call information may be requested for any call party (identified by a leglD). 

9.6.2.2 Error handling 

In any other than the "Waiting for Instruction" state the "CalllnformationRequest" operation will be handled as an error 
with the error code "UnexpectedComponentSequence". 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 in TS 29.078 [11]. 

9.7 Cancel procedure 

9.7.1 General description 

The gsmSCF uses this class 2 operation to request IM-SSF or to the gsmSRF via the IM-SSF to cancel a correlated 
previous operation. 

The gsmSRF operation to be deleted can be either a "Play Announcement" operation or a 

"PromptAndCollectUserlnformation" operation. The cancellation of an operation is indicated via a respective error 
indication, "Canceled", to the invoking entity of the cancelled "Play Announcement" or 

"PromptAndCollectUserlnformation" operation. The "Cancel" operation can also be used to cancel all outstanding 
requests and enable the state machine (IM-SSF) to go to idle. In this case the "Cancel operation does not specify any 
specific operation to be cancelled. 

9.7.1.1 Parameters 

invokelD: 

This parameter specifies which operation invokation is to be cancelled, i.e. PromptAndCollectUserlnformation 

or Play Announcement. 

allRequests: 

This parameter indicates that all active requests for EDP reports, "ApplyChargingReport" and 

"CalllnformationReport" shall be cancelled. 

NOTE: This cancellation is different from the invokelD based cancel mechanism described above. 

9.7.2 Responding entity (gsmSRF) 

In case of Cancel(invokelD) the gsmSRF via the IM-SSF is the responding entity. 

9.7.2.1 Normal procedure 

gsmSRF precondition: 

(1) A PlayAnnouncement or PromptAndCollectUserlnformation operation has been received and the gsmSRF is 
in the "User Interaction" state. 

gsmSRF postcondition: 

(1) The execution of the PlayAnnouncement or PromptAndCollectUserlnformation operation has been aborted 
and the gsmSRF remains in the "User Interaction" state. 

9.7.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 in TS 29.078 [11]. 
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9.7.3 Responding entity (IM-SSF) 

In case of Cancel(allRequests) the IM-SSF is the responding entity. 

9.7.3.1 Normal procedure 

IM-SSF precondition: 

(1) The IM-SSF-FSM is in the state "Waiting for Instructions" or "Monitoring". 
IM-SSF postcondition: 

(1) All active requests for reports and notifications have been cancelled. 

(2) In case the IM-SSF-FSM was in state "Monitoring" it shall return to idle, or 

In case the IM-SSF-FSM was in state "Waiting for Instructions" it will remain in that state. 

A subsequent call-processing operation will move the IM-SSF-FSM state to "Idle". The call, if in active state, 

is further treated by IM-SSF autonomously as a normal (non-IN-) call. 

9.7.3.2 Error handling 

Sending of return error on cancel is not applicable in the cancel "allRequests" case. Generic error handling for the 
operation related errors are described in clause 8 and the TC services which are used for reporting operation errors are 
described in clause 12 in TS 29.078 [11]. 

9.8 Connect procedure 
9.8.1 General description 

This operation is used to request the IM-SSF to perform the call processing actions to route a call to a specific 
destination. 

In general all parameters which are provided in a Connect operation to the IM-SSF shall replace the corresponding 
signalling parameter in the IP Mulimedia session control in the O-IM-BCSM and shall be used for subsequent 
processing of the IM session. The IP Multimedia session control in the T-IM-BCSM shall send corresponding signalling 
parameters to new call leg without using them in subsequent processing of the IM session. Parameters which are not 
provided by the Connect operation shall retain their value (if already assigned) in the IP Multimedia session control for 
subsequent processing of the IM session. 

9.8.1.1 Parameters 

destinationRoutingAddress : 

This parameter contains the ISDN called party numbers towards which the call is to be routed. 

destinationRoutingAddressURL: 

This parameter contains the SIP URL identifying the called party towards which the call is to be routed. 

callingPartysCategory: 

This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

originalCalledPartylD: 

This parameter carries the original destination (ISDN) number if the call is forwarded by the gsmSCF. 

originalCalledPartyURL: 

This parameter carries the SIP URL identifying the original destination party if the call has met call forwarding on 

the route to the IM-SSF. 

redirectingPartylD: 

This parameter, if present, indicates the last (ISDN) directory number the call was redirected from. 
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redirectingPartyURL: 

This parameter indicates the SIP URL identifying the last directory number the call was redirected from. 

redirectionlnformation: 

This parameter contains forwarding related information, such as redirecting reason. 

9.8.2 Responding entity (IM-SSF) 

9.8.2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship exists between the IM-SSF and the gsmSCF. 

(2) BCSM: Basic call processing has been suspended at a DP. 

(3) The IM-SSF is in state "Waiting for Instructions". 
IM-SSF postcondition: 

(1) The IM-SSF performs the call processing actions to route the call to the specified destination. 

(2) In the O-BCSM, call processing resumes at PIC Analyzejnformation. 

On receipt of this operation in the IM-SSF state "Waiting for Instructions", the IM-SSF performs the following actions: 
The IM-SSF cancels T^^„; 

If no EDPs have been armed and neither a CalllnformationReport nor an ApplyChargingReport has been 
requested, the IM-SSF goes to state "Idle". Otherwise, the IM-SSF goes to state "Monitoring". 

No implicit activation or deactivation of DPs occurs. 

Statistic counter(s) are not affected. 

9.8.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 of TS 29.078[11]. 

9.9 ConnectToResource procedure 

9.9.1 General description 

This operation is used to connect a call from the IM-SSF to a specialized resource. After successful connection to the 
gsmSRF, the interaction with the caller can take place. The IM-SSF relays all operations for the gsmSRF and all 
responses from the gsmSRF. 

9.9.1.1 Parameters 

None. 

9.9.2 Responding entity (IM-SSF) 
9.9.2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship has been established. 
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(2) The IM-SSF is in the state "Waiting for Instructions" . 
IM-SSF postcondition: 

(1) The call is switched to the gsmSRF. 

(2) A control relationship to the gsmSRF is established. 

(3) The IM-SSF moves to the state "Waiting for End of User Interaction (WFI)". T^^p is set. 

NOTE: The successful connection to the gsmSRF causes a state transition in the gsmSRF FSM from "Idle" to 
"Connected". 

9.9.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 in TS 29.078 [11]. 

9.10 Continue procedure 

9.10.1 General description 

This operation is used to request the IM-SSF to proceed with call processing at the DP at which it previously suspended 
call processing to await gsmSCF instructions. The IM-SSF continues call processing without substituting new data from 
the gsmSCF. 

9.10.1.1 Parameters 

None 

9.1 0.2 Responding entity (IM-SSF) 

9.10.2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship exists between the IM-SSF and the gsmSCF 

(2) BCSM: Basic call processing has been suspended at any DP. 

(3) IM-SSF is in state "Waiting for Instructions". 
IM-SSF postcondition: 

(1) BCSM: Basic call processing continues, if all required resumptions have been received, otherwise the only 
action is to decrement the resumption counter(s). (For details refer to 3GPP TS 23.278 [10].) 

(2) The IM-SSF remains in the same state if all resumptions have not been received; or 

The IM-SSF transits to the state "Monitoring", because at least one EDP was armed, or a 
"CalllnformationReport" or "ApplyChargingReport" was requested and no user interaction is ongoing; or 

The IM-SSF transits to the state "Idle", because no EDPs were armed and neither the "CalllnformationReport" 
nor the "ApplyChargingReport" was requested. 

9.10.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 
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9.11 ContinueWithArgument Procedure 

9.11.1 General description 

This operation is used to request the SSF to proceed with call processing at the DP at which it previously suspended call 
processing to await SCF instructions. It is also used to provide additional service related information to a user (Called 
Party or Calling Party) whilst the call processing proceeds. 

In general all parameters which are provided in a ContinueWithArgument operation to the IM-SSF shall replace the 
corresponding signalling parameter in the IP Multimedia session controland shall be used for subsequent processing of 
the IM session. Parameters which are not provided by the ContinueWithArgument operation shall retain their value (if 
already assigned) in the IP Multimedia session control for subsequent processing of the IM session. 

9.11.1.1 Parameters 

callingPartysCategory: 

This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). 

9.11.2 Responding entity (IM-SSF) 

9.1 1 .2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship exists between the IM-SSF and the gsmSCF. 

(2) BCSM: Basic call processing has been suspended at a DP. 

(3) The IM-SSF is in state "Waiting for Instructions". 
IM-SSF postcondition: 

(1) The IM-SSF performs the call processing actions to route the call to the specified destination. 

(2) In the O-BCSM, call processing resumes at PIC Analyze_Information. 

On receipt of this operation in the IM-SSF state "Waiting for Instructions", the IM-SSF performs the following actions: 
The IM-SSF cancels T^^ • 

If no EDPs have been armed and neither a CalllnformationReport nor an ApplyChargingReport has been 
requested, the IM-SSF goes to state "Idle". Otherwise, the IM-SSF goes to state "Monitoring". 

No implicit activation or deactivation of DPs occurs. 

Statistic counter(s) are not affected. 

9.11.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 of TS 29.078[11]. 

9.12 DisconnectForwardConnection procedure 
9.12.1 General Description 

This operation is used to explicitly disconnect a connection to a resource (gsmSRF) established previously with a 
"ConnectToResource" operation. It is used for a forward disconnection from the IM-SSF. An alternative solution is the 
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backward disconnect from the gsmSRF, controlled by the "DisconnectFromlPForbidden" parameter in the 
"PlayAnnouncement" and "PromptAndCollectUserlnformation" operations. 

9.12.1.1 Parameters 

None. 

9.1 2.2 Responding entity (IM-SSF) 

9.12.2.1 Normal procedure 

IM-SSF precondition: 

(1) The basic call processing has been suspended at a DP. The IM-SSF is in the state "Waiting for End of User 
Interaction". 

IM-SSF postcondition: 

(1) The connection to the gsmSRF is released. 

(2) The IM-SSF is in state "Waiting for Instructions". 

The receipt of "DisconnectForwardConnection" results in disconnecting the PE containing the gsmSRF from the 
concerned call. It does not release the connection from the IM-SSF back to the end user. 

This operation is accepted in the IM-SSF state "Waiting for End of User Interaction". On receipt of this operation in this 
state, the IM-SSF must perform the following actions: 

The initiating IM-SSF releases the connection to the gsmSRF. 

The IM-SSF resets T^gp. 

The IM-SSF FSM goes to state "Waiting for Instructions". 

9.12.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 in TS 29.078 [11]. 

9.13 EventReportBCSM procedure 
9.13.1 General description 

This operation is used to notify the gsmSCF of a call related event previously requested by the gsmSCF in a 
"RequestReportBCSMEvent" operation. The monitoring of more than one event could be requested with a 
"RequestReportBCSMEvent" operation, but each of these requested events is reported in a separate 
"EventReportBCSM" operation. 

9.13.1.1 Parameters 

eventTypeBCSM: 

This parameter specifies the type of event that is reported. 

eventSpecificInformationBCSM: 

This parameter indicates the call related information specific to the event. 

For "RouteSelectFailure" it will contain the "FailureCause", if available. 

For "O-Busy" it will contain the "BusyCause", if available. 

NOTE 1: If no BusyCause is received, the gsmSCF shall assume busy. 
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For "T-Busy" it may contain the following parameters, if available. 

- BusyCause 

if the T-Busy event is caused by an attempt to terminate to a subscriber that is not currently registered, the cause 
parameter shall contain the value "Subscriber absent (20)". Otherwise, the cause shall be set to indicate "User 
busy (17)". 



NOTE 2: If no BusyCause is received, the gsmSCF shall assume busy. 

For O-NoAnswer it will be empty. 

For O- or T- Answer it will contain the following information: 

The destination address for the call; 

For O- or T-Disconnect it will contain the "releaseCause", if available. 

leglD: 

This parameters indicates the party in the call for which the event is reported. IM-SSF will use the option 

"ReceivingSidelD" only. 

receivings idelD: 

If not included, the following defaults are assumed: 

"leglD" = 1 for the events O-Abandon and T-Abandon, 

"leglD" = 2 for the events RouteSelectFailure, O-Busy, O-NoAnswer, O-Answer, T-Busy, T-NoAnswer, and 
T-Answer. 

The "leglD" parameter shall always be included for the events O-Disconnect and T-Disconnect. 

miscCalllnfo: 

This parameter indicates Detection Point (DP) related information. 

messageType: 

This parameter indicates whether the message is a request, i.e. resulting from a "RequestReportBCSMEvent" 
with monitorMode = interrupted, or a notification, i.e. resulting from a "RequestReportBCSMEvent" with 
"monitorMode" = "notify AndContinue". 

9.1 3.2 Invoking entity (IM-SSF) 
9.13.2.1 Normal procedure 

IM-SSF precondition: 

(1)A control or a monitoring relationship exists between the IM-SSF and the gsmSCF. 

(2) The IM-SSF is in the state "Monitoring", or in state "Waiting for Instructions" (if the O/TDisconnect DP or 
O/T Answer DP is armed and encountered); or the IM-SSF is in any state, except Idle (if the O/T Abandon DP 
is armed and encountered). 

(3) The BCSM proceeds to an EDP that is armed. 
IM-SSF postcondition: 

(1) The IM-SSF stays in the state "Monitoring" if the message type was notification and there are still EDPs 
armed or a "CalllnformationReport" or "ApplyChargingReport" requested. 

(2) The IM-SSF moves to the state "idle" if the message type was notification and there are no more EDPs armed, 
no "CalllnformationReport" or "ApplyChargingReport" are requested. 
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(3) The IM-SSF moves to the state "Waiting for Instructions" if the message type was request. Call processing is 
interrupted. 

9.13.2.2 Error handling 

In case the message type is request, on expiration of T^^f before receiving any operation, the IM-SSF aborts the 
interaction with the gsmSCF and the call is given final treatment, e.g. a final announcement. 

Operation related error handling is not applicable, due to class 4 operation. 

9.14 FurnishCharginglnformation procedure 
9.14.1 General description 

This operation is used to send charging related information to a logical call record. This logical call record is CAMEL 
specific. The first FCI of a call leg leads to the generation of a logical call record. The handling of subsequent FCI's for 
a call leg depends on the presence and value of the append free format data parameter in the FCI operation. For details 

see TS 23.278 [10]. 

If an FCI operation is received for the called party when the IM-SSF is in state 'Monitoring', or is suspended in one of 
the following DPs then the charging information shall be included in the logical call record for the leg that has been or 
is to be established: 

Collectedjnfo; 

0_Answer; 

Terminating_Attempt_Authorised; or 

T_Answer. 

If an FCI operation is received for the called party when the IM-SSF is suspended in any other DP then the charging 
information shall be included in the logical call record created for the last failed or disconnected called party. 

9.14.1.1 Parameters 

fCIBillingChargingCharacteristics: 

This parameter contains the following sub-parameters; 

fCIBCCC AMELsequence 1 : 

This parameter contains the following sub-parameters; 

freeFormatData: 

This parameter contains free-format billing and/or charging characteristics; 

party ToCharge: 

This parameter indicates the party to bill and/or charge; 

appendFreeFormatData: 

This parameter indicates whether previous FCI free format data is appended or overwritten. See 

3GPPTS 23.278 [10]. 
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9.1 4.2 Responding entity (IM-SSF) 

9.14.2.1 Normal procedure 

IM-SSF preconditions: 

(1) IM-SSF State "Waiting for Instructions" or 

IM-SSF State "Waiting for End of User Interaction" or IM-SSF state "Monitoring". 

IM-SSF postcondition: 

( 1 ) No FSM state transition. 

On receipt of this operation the IM-SSF performs actions to create the call record if necessary, and writes the free- 
format information carried in the operation into the call record. An FCI operation will create a Logical Call Data Record 
(CDR) if such a record does not already exist for the indicated leg. 

The Logical CDRs will be associated for a given call into one or more physical CDRs, as specified in 3GPP TS 22.105. 

A logical CDR is output when a disconnection event is propagated to the Leg associated with it, or when a Connect 
operation to create a connection to a Follow-on Called Party is received. Successive FCIs indicating the calling leg 
(legl) may overwrite data from previously received FCI(s) indicating that calling leg during that entire call or call 
attempt. Successive FCIs indicating the called leg (leg2) may overwrite any previously received data from FCI(s) 
indicating that called leg until the called leg representing that particular called party number is released from or releases 
the call. When a new called party is created as a result of a follow-on call, and an FCI indicating the called leg is 
received, then a new CAMEL Logical CDR is created for that portion of the call. From then on, any subsequent FCIs 
for the called party may overwrite the data from any previous FCI(s) for the called leg presenting that particular called 
party number; however, CAMEL Logical CDR(s) that have been output already are not affected. 

No CAMEL Logical CDR is output at the end of a user interaction. 

9.14.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 in TS 29.078 [11]. 

9.15 InitialDP procedure 
9.15.1 General description 

This operation is sent by the IM-SSF after detection of a TDP-R in the BCSM, to request the gsmSCF for instructions to 
complete the call. 

9.15.1.1 Parameters 

serviceKey: 

This parameter indicates to the gsmSCF the requested IN service. It is used to address the required application/SLP 

within the gsmSCF (not for SCP addressing). 

calledPartyN umber: 

This parameter contains the ISDN number used to identify the called party in the forward direction, i.e. see 

EN 300 356-1 [2]. 

- calledPartyURL: 

This parameter contains the SIP URL identifying the called party in the forward direction. 

callingPartyNumber: 

This parameter carries the calling party (ISDN) number to identify the calling party or the origin of the call. See 

EN 300 356-1 [2] Calling Party Number signalling information. 
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callingPartyURL: 

This parameter contains the SIP URL identifying the calUng party or the origin of the call. 

callingPartysCategory: 

Indicates the type of calling party (e.g. operator, pay phone, ordinary subscriber). See EN 300 356-1 [2] Calling 

Party Category signalling information. 

originalCalledPartylD: 

This parameter carries the original destination (ISDN) number if the call has met call forwarding on the route to the 

IM-SSF. See EN 300 356-1 [2] Original Called Number signalling information. 

originalCalledPartyURL: 

This parameter carries the SIP URL identifying the original destination party if the call has met call forwarding on 

the route to the IM-SSF.. 

mediaType: 

This parameter indicates the media type associated with the SIP call (e.g. video, audio, application or data). 

- eventTypeBCSM: 

This parameter indicates the armed BCSM DP event, resulting in the "InitialDP" operation. 

redirectingPartylD : 

This parameter indicates the last (ISDN) directory number the call was redirected from. 

redirectingPartyURL: 

This parameter indicates the SIP URL identifying the last directory number the call was redirected from. 

redirectionlnformation: 

It contains forwarding related information, such as redirecting reason. 

See ITU-T Recommendation Q.763 [5] Redirection Information signalling information. 

- iMSI: 

IMSI of the mobile subscriber for which the service is invoked. For encoding see 3GPP TS 29.002 [9]. 

subscriberState: 

The state of the mobile subscriber for which the service is invoked. The possible states are busy, idle and not 

reachable. For encoding see 3GPP TS 29.002 [9]. 

- sipCallld: 

This parameter is a unique identifier for the SIP call assigned by the CSCF. 

- iMSSFAddress: 

This parameter gives the address assigned to the IM-SSF. For encoding see 3GPP TS 29.002 [9]. 

time&Timezone: 

This parameter contains the time that the IM-SSF was triggered, and the time zone that the invoking IM-SSF 

resides in. 

cGEncountered: 

This parameter indicates the type of gapping the related call has been subjected to, if any. 

cause: 

This parameter indicates the release cause which triggered the event: 

For "RouteSelectFailure" it will contain the "FailureCause", if available. 

For "T-Busy" it may contain the following parameters: 

if the T-Busy event is caused by an attempt to terminate to a subscriber that is not currently registered, 
the cause parameter shall contain the value "Subscriber absent (20)". Otherwise, the cause shall be set to 
indicate "User busy (17)". 
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9.1 5.2 Invoking entity (IM-SSF) 

9.15.2.1 Normal procedure 

IM-SSF precondition: 

(1) An event fulfilling the criteria for the DP being executed has been detected. 

(2) Call gapping and SS7 overload are not in effect for the call. 

IM-SSF postcondition: 

(1) A control relationship has been established if the DP was armed as a TDP-R. The IM-SSF moves to the State 
"Waiting for Instructions". 

The address of the gsmSCF is fetched from the valid CSI. The IM-SSF provides all available parameters. Otherwise the 
IM-SSF proceeds with call handling without CAMEL Service. 

The IM-SSF application timer T^^p is set when the IM-SSF sends "InitialDP" for requesting instructions from the 
gsmSCF. It is used to prevent excessive call suspension time. 

9.15.2.2 Error handling 

If the destination gsmSCF is not accessible then the call proceeds according to the 'default call handling' parameter in 
the CSI. 

On expiration of T^^p before receiving any operation, the IM-SSF aborts the interaction with the gsmSCF and the call 
continues according to the 'default call handling' parameter in the CSI. 

If the calling party abandons after the sending of "InitialDP", then the IM-SSF aborts the control relationship by means 
of an abort to TC. Note that TC will wait until the first response message from the gsmSCF has been received before it 
sends an abort to the gsmSCF (see also clause 12 of TS 29.078 [11]). 

Generic error handling for the operation related errors are described in clause 8 and the TC services that are used for 
reporting operation errors are described in clause 12 of TS 29.078 [11]. 

9.16 ReleaseCall procedure 

9.16.1 General description 

This operation is used by the gsmSCF to tear down a call at any phase. This operation may not be sent to an assisting 
IM-SSF. 

9.16.1.1 Parameters 

releaseCause: 

A number giving an indication to the IM-SSF about the reason of releasing this specific call. This may be used 

by IM-SSF for generating specific tones to the different parties in the call or to fill in the "cause" in the release 

message. 

9.1 6.2 Responding entity (IM-SSF) 
9.16.2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship exists between gsmSCF and IM-SSF. 

(2) The IM-SSF is in state "Waiting for Instructions" or state "Monitoring". 
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IM-SSF postcondition: 

(1) The IM-SSF changes to state "Idle" after sending any outstanding "CalllnformationReport" or 

"ApplyChargingReport". Possible armed EDPs are ignored. All connections and resources related to the call 
are released. 

9.16.2.2 Error handling 

Operation related error handling is not applicable, due to class 4 operation. 

9.17 RequestReportBCSMEvent procedure 

9.17.1 General description 

This operation is used to request the IM-SSF to monitor for a call-related event (e.g., BCSM events such as busy or no 
answer), then send a notification back to the gsmSCF when the event is detected. 

9.17.1.1 Parameters 

bcsmEvents: 

This parameter specifies the event or events of which a report is requested. 

- eventTypeBCSM: 

This parameter specifies the type of event of which a report is requested. 

monitorMode: 

This parameter indicates how the event shall be reported. When the "monitorMode" is "interrupted", the event 
shall be reported as a request, if the "monitorMode" is "notify AndContinue", the event shall be reported as a 
notification, if the "monitorMode" is "transparent", the event shall not be reported. 

- leglD: 

This parameter indicates the party in the call for which the event shall be reported. gsmSCF will use the option 
"sendingSidelD" only. 

sendingSidelD: 

If not included, the following defaults are assumed for LegID: 

"leglD" = 1 for the events O-Abandon and T-Abandon, 

"leglD" = 2 for the events RouteSelectFailure, O-Busy, O-NoAnswer, O-Answer, T-Busy, T-NoAnswer, 
and T-Answer. 

The "leglD" parameter shall always be included for the events O-Disconnect and T-Disconnect. 

- dPSpecificCriteria: 

This parameter indicates information specific to the EDP to be armed. 

applicationTimer: 

This parameter indicates the NoAnswer timer value for the NoAnswer event. If the user does not answer 
the call within the allotted time, the IM-SSF reports the event to the gsmSCF. This timer shall be shorter 
than the network no-answer timer. 

9.1 7.2 Responding entity (IM-SSF) 
9.17.2.1 Normal procedure 

IM-SSF precondition: 

(1) A control relationship exists between the IM-SSF and the gsmSRF. 
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(2) The IM-SSF is in either the state "Waiting for Instructions" or the state "Monitoring". 

NOTE: In state "monitoring" only requests to disarm detection points (with MonitorMode set to 

"Transparent") or send notifications of events (with MonitorMode set to "Notify AndContinue") shall 
be accepted. 

IM-SSF postcondition: 

(1) The requested EDPs have been armed or disarmed as indicated. 

(2) Previously requested events are monitored until ended by a transparent monitor mode, until the end of the call, 
until the EDPs are detected or until the corresponding leg is released. 

(3) The IM-SSF remains in the same state, unless all EDPs have been disarmed and no CalllnformationReport or 
ApplyChargingReport has been requested; in the latter case the IM-SSF moves to the state "Idle". 

9.17.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 in TS 29.078 [11]. 

9.18 ResetTimer procedure 

9.18.1 General description 

This class 2 operation is used by the gsmSCF to refresh the Tssf application timer, in order to avoid the Tssf time-out at 
the IM-SSF. 

9.18.1.1 Parameters 

timerlD: 

This parameter has a default value identifying the Tssf timer. 

timerValue: 

This parameter specifies the value to which the Tssf is to be set. 

9.1 8.2 Responding entity (IM-SSF) 

9.18.2.1 Normal procedure 

IM-SSF precondition: 

(1) Basic call processing has been suspended at a DP. 

(2) The IM-SSF is in the "Waiting for Instruction" state or in the "Waiting for End of User Interaction" state or in 
the "Waiting for End of Temporary Connection" state. 

IM-SSF postcondition: 

(1) The Tssf timer has been reset. 

(2) The IM-SSF remains in the same state. 

9.18.2.2 Error handling 

Generic error handling for the operation related errors are described in clause 8 and the TC services which are used for 
reporting operation errors are described in clause 12 in TS 29.078 [11]. 
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